Team Geek ― Google のギークたちはいかにしてチームを作るのか
https://www.oreilly.co.jp/books/images/picture978-4-87311-630-3.gif
ミッションステートメント
本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。
感想 nobuoka.icon
時間を大事にするのも、大事
内容メモ
ソフトウェア開発はチームスポーツであり、技術的要因と同じぐらい人的要因が影響する
1 章 : 天才プログラマの神話
スーパースターへのあこがれの裏返し : 自分のコードを見た他人から、自分が天才じゃないと思われるのではないか
自分のアイデアを他人に見せることで、他人が先に手を出すかもしれない
隠しているのは大きなリスク (誰にも相談できずにうまくいかない可能性)
早い段階から共有することでつまづきを回避もできるし、バス係数を高められる 進捗も速められる
集中してコードを書く時間は必要だが、それ以上にチームとの広帯域かつ高速な接続が不可欠
強いフィードバックループ
コードレベルのもそうだし、プロジェクトレベルでも → チームで仕事をする エゴをなくす : 周囲に合わせるべきというわけではないが、周囲に合わせる方がうまくいく
批判を受け取る側には謙虚さと 「他の人が自分たちに恩恵をもたらしてくれる」 という信頼が必要 「相手が間違っている」 という風に言うのではなく、「自分が理解できない」 という謙虚な姿勢でコメントする 過去に失敗したことがないのであれば、それは革新的ではないか、リスクをとっていない証拠
影響を受けやすくすれば影響を与えやすくなる
弱いところを見せれば強い人だと思われる
自分の意見を主張するときには、まずは相手の話を聞く
間違いや能力不足を認めることは、長期的には立場を向上させる
2 章 : 素晴らしいチーム文化を作る
チームの文化の定義・維持・防御に責任を持つのはチームメンバー
チームの文化を気にかける必要があるのは、そうしないと新来者が持つ望ましくない文化が広がりかねないため
新来者はリーダーではなくチームメンバーから文化を学ぶ
強固な文化は自己選択的 : 文化に適合する人を惹きつける
優秀なエンジニアは他の優秀なエンジニアと働きたいと考える
プロダクト開発への参加だけでなく、プロダクトの意思決定プロセスにも参加できるように = 合意ベースのマネジメント
プロダクトの成功のため、短時間で意思決定する必要がある場合もある → リーダーに意思決定をゆだねる
積極的な人は静かな環境でもうまくやれるが、内向的な人は騒がしい環境が苦手、というのもある 積極的な文化はのんびりした人に強いが、静かな環境は積極的な人に弱い
うまくいっている効率的なエンジニアリング文化は、多くのコミュニケーションチャネルを使う
全員がチームの方向性に合意して全てを正確に理解するためには相当な手間が必要
コミュニケーションの原則 : 同期コミュニケーションの人数を減らし、非同期コミュニケーションの人数を増やす
高いレベルの同期 (共通の目標を持ち、進捗を伝えるためのベストプラクティス)
地理的障害のあるチームで働く場合も、遠隔地の人に議論が伝わるようにメーリングリストなどを活用
設計文書を作ること
日常的な議論
メーリングリストで、開発の議論やコードレビュー、ユーザーの議論、アナウンスや通知、管理上の議論などを行う nobuoka.icon オンラインチャットがあればメーリングリストは不要ってことはないのかな
課題管理ツール
3 章 : 船にはキャプテンが必要
キャプテンのいない船が浮かんでいるだけであるように、リーダーのいないチームもただのギークの集団
伝統的なマネジャーとリーダー
伝統的なマネジャーはどうやって仕事を完了させるかを考える リーダーは何ができるかを考える (どうやって仕事を完了させるかはチームに考えてもらう) リーダーの種類 : 人間的なリーダーと技術的なリーダー エンジニアがマネジャーになりたくないのは？
コードを書く時間が減るから → マネジャーの成果の指標を間違えている
マネジャーになるべき理由
自分をスケールできる
マネジャーに向いているかもしれない
チームメンバーをスイートスポットに入れるために方向性を与えることとモチベーションを高める必要性 熟達には、エンジニアが新しいスキルを学び、既存のスキルを向上させる機会をつくる 4 章 : 有害な人に対処する
人ではなく、ネガティブな振る舞いを排除する文化を作る
章のタイトルに 「有害な人」 と書いているが、あくまでも振る舞いを排除する
脅威 : チームの注意と集中が脅かされる
他人の時間を尊重しない : 悪意はなくても、プロジェクトの状況を把握せずに自分のアイデアを話して対応に時間をとらせるとか エゴ : 合意の決定を受け入れられなかったり、異なる視点の意見に耳を傾けられなかったり、妥協できない人 権利を与えすぎる : 要求だけするような人は、貢献する気のない人 権利を与えすぎるとトロルのような振る舞いになりえる 未熟なコミュニケーションと複雑なコミュニケーション
完璧主義 : 一見問題なさそうだが、停滞してしまう 有害な振る舞いを追い出すには
完璧主義者には別の方向性を伝える (完璧主義のテーマを変える) 例えばテストや手戻りの確認を担当してもらうとか
エサを与えない : チームをわざと怒らせるようなトロルに対しては、黙殺する 感情的にならない : 相手の機嫌をとるとか、相手にする価値のない事柄に時間を割くとかはしない
技術的な議論に戻す : 言葉が悪くても学べるところはあるかもしれない
振る舞いはともかく得られるものがあるなら、技術的な部分にのみ焦点を当ててやり取りを行う
優しくすることで近づきづらくする
諦めるべき時もある : 直接的に止めるように伝える
長期的に考える
長期的にプロジェクトにメリットがあるか？ 衝突を有益な方法で解決できるか？ のどちらも NO なら即刻止めさせるべき
技術的に優秀だからといって、文化が脅かされるのであればその振る舞いは受け入れてはならない
技術的な優秀さは代替可能
5 章 : 組織的操作の技法
組織的操作 : 官僚的な会社で働くための小手先のテクニック オフィスの政治家 : 人間関係を操って自分の思うようにすすめようとする
影響力のある人になるのではなく、影響力のある人を探す
悪い組織
組織を操作する
許可を求めるより寛容を求める
いつも自身の正当化をしていたりすると社内政治のための資本を消費してしまう
戦略的にやる : 勝てる見込みのある重要な争いを選択する
草の根レベルでアイデアを受け入れてもらう
複数の人から話を聞いていると重要だと認識する
悪い習慣をやめるのは難しいが、良い習慣と置き換えることはできる (禁煙もそう) 自分の仕事を完了させることだけに集中して他のことを排除していると機会が少ない
他人を手伝うことで、また今度助けてもらえる、というような親切の経済がある 安全なポジションまで昇進する : 昇進することで自分の運命をコントロールできるようになっていく
強力な友達を探す : どの会社にもある 「裏」 の組織図で、権力や影響力を把握する
次善策 : 逃げる
6 章 : ユーザーも人間
「成功」 と言えるためには、実際にプロダクトを使ってもらってその人が幸せにならなければならない
ソフトウェアを使ってもらい、フィードバックを受けてプロダクトを改良する
ユーザーエンゲージメントの 3 フェーズ
利用開始前の認知
利用時の体験
利用開始後にうまくやり取りする方法
マーケティングの人は感情操作に精通
小さく約束して大きく届ける
業界のアナリストと付き合う
Google の有名なモットー : ユーザーに集中すれば、他のことはすべてついてくる
複雑さを隠す : Google の検索インターフェイスとか
複雑さを隠したために不便になってはいけない
抽象化が漏れる可能性も想定する
ユーザーとの関係管理
関連書籍